home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Magnum One
/
Magnum One (Mid-American Digital) (Disc Manufacturing).iso
/
d7
/
dblink13.arc
/
X00.DOC
< prev
next >
Wrap
Text File
|
1990-11-22
|
15KB
|
335 lines
X.00 Low Level Communications Driver
X.00 Copyright (c) 1987 by Raymond L. Gwinn
12469 Cavalier Drive
Woodbridge, Virginia 22192
All rights reserved
You are granted a conditional license to use X00.SYS in
conjunction with the D'Bridge EMAIL system by Chris Irwin and
other programs distributed with conditions of use similar to that
of D'Bridge. The user of X00.SYS must meet the conditions of
both the legitimate use of D'Bridge and the intended legitimate
use of D'Bridge. X00 may not be distributed by anyone where fees
are charged or where requests for donations are made without
prior written permission of Raymond L. Gwinn. Further, the
author reserves the right to revoke the license and/or prohibit
the use of X00.SYS by anyone for any reason at any time.
The latest version of X00.SYS is available for down-loading from
The Renex BBS (FidoNet 109/639), 703-690-7950.
Unlike most software developers, I make Beta/test versions of
X00.SYS readily available. This has caused some confusion among
various users. That is, they are using beta versions of X00.SYS
and think they are using a fully tested (if there is such a
thing) versions. Starting with version 1.02 of X00.SYS I am
going to use the following method in numbering the versions. If
the version number ends with an odd number, then it is a beta
version. If it ends with an even number, then it is a tested
version that is (relatively) safe for general use. Then,
versions 1.01, 2.15 and 1.07 would be beta versions. Versions
1.00, 1.02, 2.00 and 2.14 would not be beta versions. The beta
versions will always have (and always have had) a lower case
letter appended to the version number. For example, 1.01f is one
way that you will see beta versions identified. If you find a
problem in a beta/test version, let me know about it by direct
mail.
X00.SYS and associated utilities comes with no guarantees or
warranties. Use it at your own risk.
X00.SYS provides enhanced/extended support of INT 14H functions.
Documentation of the enhanced/extended functions can be found in
the included file FOSSIL.DOC by Vincent E. Perriello.
DoubleDOS. Since writing X.00 I have learned more about DDos
than I ever wanted to know. A few rules for DDos users that I
know are: 1 - Do not assign the comm ports in DDCONFIG.SYS, 2-
Be sure to execute CAPTURE after you execute DOUBLEDO. To be
safe, execute CAPTURE in both partitions. 3 - If you have
problems with your clock, try the Defer option. 4 - Be sure to
replace ANSI.SYS with DBLDANSI.SYS. For some reason, I had
problems if the TOP partition was not delayed. That is, the
BOTTOM partition must initialize before the TOP partition does.
The semi-formal syntax for the statement to be placed in the
CONFIG.SYS file is as follows:
DEVICE=X00.SYS <options>
<options> ::= <none> | <eliminate> <defer> <port specs> <baud>
<size> <fifospec>
<none> ::=
<eliminate> ::= E{LIMINATE}
<defer> ::= D{EFER}
<fifospec> ::= NOFIFO
<baud> ::= B,<port number>,<baud rate>
<size> ::= R=<receive buffer size> T=<transmit buffer size>
<receive buffer size> ::= <buffer size>
<transmit buffer size> ::= <buffer size>
<nasty> ::=N{ASTY}
<buffer size> ::= 256 | 512 | 1024 | 2048 | 4096 | 8192 | 16384 |
32768
<baud rate> ::= 300 | 1200 | 2400 | 4800 | 9600 | 19200 | 38400
<port spec> ::= <number of ports> | <hardware port assignment>
<number of ports> ::= 0 | 1 | 2 | 3 | 4
<hardware port assignment> ::= <port number> = <assignment>
<port number> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7
<assignment> ::= <logical> | <absolute>
<logical> ::= <comn> {, <irqn>}
<comn> ::= <COM1> | <COM2> | <COM3> | <COM4>
<irqn> ::= <IRQ0> | <IRQ1> ........ <IRQ15>
<absolute> ::= <hex port address> , <irqn>
<hex port address> ::= Any hex number 0 through 0FFFF. The first
character must be 0 through 9.
The simplest statement for the CONFIG.SYS file is as follows:
DEVICE=X00.SYS
This statement will be all that is required on the vast majority
of D'Bridge systems. It says that you wish to support one comm
port.
DEFER - DO NOT USE THIS OPTION UNLESS YOU UNDERSTAND ITS PURPOSE
AND YOU NEED TO USE IT. IF YOUR SYSTEM WORKS WITHOUT THIS
OPTION, THEN DO NOT USE IT. If you needed to use this option
with past versions of X00.SYS then try this version without it.
Do not automatically assume that you still need it. At least
half of the reported problems with X00 have resulted from the
casual use of this option. This option specifies that X00.SYS is
not to take any DOS interrupt vectors during the boot process.
If DEFER is specified then CAPTURE must be executed prior to
executing OPUS. Your AUTOEXEC.BAT file is the best place to
execute CAPTURE. With MultiLink, CAPTURE should be executed
before multi-tasking is started. However, as with 99% of all
systems, MultiLink systems should work correctly (and better)
without the DEFER option. Unless you are using some strange
software, you should not need to use the DEFER option. If your
system does not boot correctly with X00.SYS then try the DEFER
option followed by CAPTURE in your AUTOEXEC.BAT file. X00.SYS
only checks for the D in DEFER.
ELIMINATE will eliminate the 5 second commercial at boot time
(which is a direct screen memory write).
NOFIFO will cause X00 to NOT enable the FIFOs of the National
16550. Some Multi-Tasking systems have problems when the 16550's
FIFOs are enabled. NOFIFO allows the user to override the
automatic use of the 16550's FIFOs by X00.
Number of ports. When you wish to use the default IBM/Opus
communication port addresses and IRQs, you should simply specify
the number of ports that you wish to support (the default is 1).
Although X00 V1.00 and up can support up to 8 ports, you can only
specify 0 through 4 supported ports. The reason is that there is
only 4 defined ports (COM1, COM2, COM3, COM4) that X00 can
default to. If you use the absolute method (described later) you
can specify up to 8 devices. X00 assumes that COM1 and COM2 are
addressed as originally defined by IBM. The default hardware
characteristics of COM3 and COM4 are 03E8H, IRQ4 and 02E8H, IRQ3
respectively. This seems to be a defacto standard, although no
real standard exists that I know of.
With the software that uses FOSSIL drivers today, 2 ports is all
that can reasonably be used. However, X00 allows you to make one
or both of those ports COM3 and/or COM4 or non-standard hardware.
The T and R options (or help, the sky is falling). Trying to be
all comm drivers to all protocols on all computers (especially
betas) is not easy. The T and R options allow you to specify the
size of the transmit and receive buffers. The buffer size must
be a power of 2. The sum total, in bytes, of all buffers can not
exceed 48k bytes. For example, DEVICE=X00.SYS T=32768 R=16384 is
valid (only one port). However, DEVICE=X00.SYS 2 T=16384 R=16384
is not valid (2 ports each with a 16k transmit and receive buffer
= 32k per port or 64k). In the second example the total buffer
size exceeds the maximum of 48k. X00 SHOULD (but not
necessarily) beep the bell and display an error message at boot
time if you attempt to define too much buffer space. Also with
this option, the default buffer size has been increased to 4k (it
was 1k) for both the transmit and receive buffers.
The <baud> option allows you to lock the baud rate from the
computer to the modem. When this option is specified for a port,
the baud rate from the computer to the modem will remain constant
regardless of what the application program (such as Opus)
requests the baud rate to be. This option is to accommodate the
higher speed modems like the Telebit TrailBlazer and USR HST
modems. When this option is used, RTS/CTS handshaking is implied
(forced) even if the application program has not requested
RTC/CTS handshaking. Both Telebit and USR recommend in their
manuals that the computer to modem baud rate be constant. My
personal experience has show that both modem types operate better
when the computer to modem baud rate is faster than the actual
phone line baud rate.
The <nasty> option makes X00 get very aggressive about keeping
the COMM interrupts. Many multi-tasking systems and some TSRs
mess around with the COMM IRQs and thus, slow things down. I
finally figured out how to keep them at bay. However, the NASTY
option may cause problems on some systems. If you are running a
multi-line system, try the NASTY option. If it does not crash,
you will probably see improved throughput. Running COMM type
code in LIM memory may crash with NASTY enabled. The default for
NASTY is disabled.
You may specify 0 as the number of FOSSIL comm ports. In this
case, all FOSSIL code is released to DOS during booting and
X00.SYS will occupy only about 1K of memory. The 0 comm port
option is primarily for non IBM systems (such as DEC and Tandy)
that must use other FOSSIL drivers. These systems can then use
OUTER without carrying the overhead of the unusable FOSSIL code.
If you are using Opus and you specify 0 FOSSIL comm ports to
X00.SYS, you must have another FOSSIL driver, such as OPUSCOMM
loaded into memory for Opus to use.
The required communications buffers are allocated dynamically.
All code used for initialization is overlaid by the buffers or
released to DOS by X00 when it completes initialization at boot
time.
IRQs. The AT's additional 8 IRQs are supported. X00 can support
multiple ports on a single interrupt. When multiple ports are
assigned to a single interrupt, X00 will poll each of the ports
to find the interrupting device(s).
If you plan to reassign the port(s) to a non-standard
configuration or use some strange hardware, it is best to think
in port numbers instead of COMn. The Opus documentation refers
to COM1 and COM2. However, when Opus communicates with a FOSSIL
driver, it calls COM1 device/port 0 and COM2 is device/port 1.
So if you want to keep your head in order, you can edit the CTL
files and (except where you can't) change all occurrences of COM1
to PORT 0 and COM2 to PORT 1.
Some examples of CONFIG.SYS statements are as follows:
DEVICE = X00.SYS E
Which means one port, no commercial.
DEVICE = X00.SYS 2
Allocate space for buffers (at the default size of 4k) and
provide support for COM1 and COM2.
DEVICE = X00.SYS T=1024 R=4096
One port supported, the transmit buffer is to be 1k and the
receive buffer is to be 4k.
DEVICE = X00.SYS 2 B,1,19200
Same as the above except COM2 will always operate at 19200 baud.
COM1 will operate at the baud rate set by the application
program.
DEVICE = X00.SYS 2 B,0,19200
Same as the above except COM1 is fixed at 19200. COM2 will
operate at the baud rate set by the application program.
DEVICE = X00.SYS 2 B,0,19200 B,1,9600 NOFIFO
In this example the baud rate for COM1 is locked at 19200 baud
and COM2 is locked at 9600 baud. Additionally, the FIFOs of the
National 16550 will not be enabled.
DEVICE = X00.SYS 0=COM3
One port supported but, use COM3 on IRQ4 (the default). Opus
will think (and must be told in the CTL file) that it is using
COM1 in this case.
DEVICE = X00.SYS 0=COM3,IRQ4
Exactly the same as above.
DEVICE = X00.SYS 0=COM3,4
Exactly the same as above.
DEVICE = X00.SYS 0=COM3,IRQ1
Same as above except IRQ1 is to be used.
DEVICE = X00.SYS 0=COM4 1=COM3
Two ports supported, Opus thinks COM4 is COM1 and that COM3 is
COM2. Use the default IRQs for COM4 and COM3.
DEVICE = X00.SYS 0=COM4 1=COM3 NASTY
Exactly the same as the previous example except the NASTY option
is enabled. Note that NASTY may cause problems on some systems.
Now some absolute assignment examples. When hex port addresses
are used, the IRQ must be specified.
DEVICE = X00.SYS 0=0FE8,IRQ4
Support one serial (8250) device with a base port address of
0FE8H and use IRQ4
DEVICE = X00.SYS 0=3F8,IRQ4 1=2F8,IRQ4
Support 2 serial devices at the given hex port address and both
will interrupt on IRQ4.
etc, etc, etc.
If you are not confused by now, I am, so I'm giving up.